A taxonomy of tool-related issues affecting the adoption of model-driven engineering

Although poor tool support is often blamed for the low uptake of model-driven engineering (MDE), recent studies have shown that adoption problems are as likely to be down to social and organizational factors as with tooling issues. This article discusses the impact of tools on MDE adoption and practice and does so while placing tooling within a broader organizational context. The article revisits previous data on MDE use in industry (19 in-depth interviews with MDE practitioners) and reanalyzes that data through the specific lens of MDE tools in an attempt to identify and categorize the issues that users had with the tools they adopted. In addition, the article presents new data: 20 new interviews in two specific companies—and analyzes it through the same lens. A key contribution of the paper is a loose taxonomy of tool-related considerations, based on empirical industry data, which can be used to reflect on the tooling landscape as well as inform future research on MDE tools

The Impact of Requirements on Systems Development Speed: A Multiple-Case Study in Automotive

Automotive\ua0manufacturers have historically adopted rigid\ua0requirements\ua0engineering processes. This allowed them to meet safety-critical\ua0requirements\ua0when producing\ua0a\ua0highly complex and differentiated product out of the integration of thousands of physical and software components. Nowadays, few software-related domains are as rapidly changing as the\ua0automotive\ua0industry.\ua0In\ua0particular, the needs of improving\ua0development\ua0speed\ua0are increasingly pushing companies\ua0in\ua0this domain toward new ways of developing software.\ua0In\ua0this paper, we investigate how the goal to increase\ua0development\ua0speed\ua0impacts how\ua0requirements\ua0are managed\ua0in\ua0the\ua0automotive\ua0domain. We start from\ua0a\ua0manager perspective, which we then complement with\ua0a\ua0more general perspective. We used\ua0a\ua0qualitative\ua0multiple-case\ua0study, organized\ua0in\ua0two steps.\ua0In\ua0the first step, we had 20 semi-structured interviews, at two\ua0automotive\ua0manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists.\ua0In\ua0the second step, we validated our results with 12 more interviews, covering nine additional respondents and three recurring from the first step.\ua0In\ua0addition to validating our qualitative model, the second step of interviews broadens our perspective with technical experts and change managers. Our respondents indicate and rank six aspects of the current\ua0requirements\ua0engineering approach that\ua0impact\ua0development\ua0speed. These aspects include the negative\ua0impact\ua0of\ua0a\ua0requirements\ua0style dominated by safety concerns as well as decomposition of\ua0requirements\ua0over many levels of abstraction. Furthermore, the use of\ua0requirements\ua0as part of legal contracts with suppliers is seen as hindering fast collaboration. Six additional suggestions for potential improvements include domain-specific tooling, model-based\ua0requirements, test automation, and\ua0a\ua0combination of lightweight upfront\ua0requirements\ua0engineering preceding\ua0development\ua0with precise specifications post-development. Out of these 12 aspects, seven can likely be addressed as part of an ongoing agile transformation. We offer an empirical account of expectations and needs for new\ua0requirements\ua0engineering approaches\ua0in\ua0the\ua0automotive\ua0domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical\ua0systems

Architecture evaluation in continuous development

Context: In automotive, stage-gate processes have previously been the norm, with architecture created mainly during an early phase and then used to guide subsequent development phases. Current iterative and Agile development methods, where the implementation evolves continuously, changes the role of architecture. Objective: We investigate how architecture evaluation can provide useful feedback during development of continuously evolving systems. Method: Starting from the Architecture Tradeoff Analysis Method (ATAM), we performed architecture evaluation, both in a national research project led by an automotive Original Equipment Manufacturer (OEM), and at the OEM, in the context of continuous development. This allows us to include the experience of several architects from different organizations over several years. Using data produced during the evaluations we perform a post-hoc analysis to derive initial findings. We then validate and refine these findings through a series of focus groups with architects and industry experts. Findings: We propose principles of continuous evaluation and evolution of architecture, and based on these discuss a roadmap for future research. Conclusion: In iterative development settings, the needs are different from what typical architecture evaluation methods provide. Our principles show the importance of dedicated feedback-loops for continuous evolution of systems and their architecture

How do practitioners perceive the relevance of requirements engineering research? An ongoing study

The relevance of Requirements Engineering (RE) research to practitioners is a prerequisite for problem-driven research in the area and key for a long-term dissemination of research results to everyday practice. To understand better how industry practitioners perceive the practical relevance of RE research, we have initiated the RE-Pract project, an international collaboration conducting an empirical study. This project opts for a replication of previous work done in two different domains and relies on survey research. To this end, we have designed a survey to be sent to several hundred industry practitioners at various companies around the world and ask them to rate their perceived practical relevance of the research described in a sample of 418 RE papers published between 2010 and 2015 at the RE, ICSE, FSE, ESEC/FSE, ESEM and REFSQ conferences. In this paper, we summarize our research protocol and present the current status of our study and the planned future steps.Peer ReviewedPostprint (author's final draft

Sustainability Competencies and Skills in Software Engineering: An Industry Perspective

Achieving the UN Sustainable Development Goals (SDGs) demands adequate levels of awareness and actions to address sustainability challenges. Software systems will play an important role in moving towards these targets. Sustainability skills are necessary to support the development of software systems and to provide sustainable IT-supported services for citizens. While there is a growing number of academic bodies, including sustainability education in engineering and computer science curricula, there is not yet comprehensive research on the competencies and skills required by IT professionals to develop such systems. This study aims to identify the industrial sustainability needs for education and training from software engineers' perspective. We conducted interviews and focus groups with experts from twenty-eight organisations with an IT division from nine countries to understand their interests, goals and achievements related to sustainability, and the skills and competencies needed to achieve their goals. Our findings show that organisations are interested in sustainability, both idealistically and increasingly for core business reasons. They seek to improve the sustainability of processes and products but encounter difficulties, like the trade-off between short-term financial profitability and long-term sustainability goals. To fill the gaps, they have promoted in-house training courses, collaborated with universities, and sent employees to external training. The acquired competencies make sustainability an integral part of software development. We conclude that educational programs should include knowledge and skills on core sustainability concepts, system thinking, soft skills, technical sustainability, sustainability impact and measurements, values and ethics, standards and legal aspects, and advocacy and lobbying

Bridging model-based and language-based security

We present a way to support the development of software applications that takes into account confidentiality issues, and how the developed code can be automatically verified. We use the Unified Modelling Language (UML) together with annotations to permit confidentiality to be considered during the whole development process from requirements to code. We have provided support for software development using UML diagrams so that the code produced can be be validated by a language-based checker, in our case Jif (Java information flow). We demonstrate that the combination of model-based and language-based security is compelling

Use Cases are more than System Operations

Abstract. Correctly written use cases can be an important artifact for describing how a software system should behave. Use cases should be informal enough to permit anyone in a software project to understand them, in particular the customer (often lacking a formal background). One consequence of adopting use cases to, for example, MDA (Model Driven Architecture) can be an increasing level of formalism, which can severely limit understanding of use cases. Also, too few guidelines for how to write use cases make them both hard to write and understand. Finding the right level of formalism is the topic of this paper. We suggest a new way of writing the action steps of use cases by introducing action blocks. The introduction of action blocks makes use cases more formal, but still understandable. In addition, action blocks supports the creation of contracts for system operations. In this paper we also argue that treating system operations as use cases is a misuse of use cases system operations and use cases should be separate artifacts. One should be able to obtain several system operations from a use case, otherwise there is no dialog (process) between actors and use cases. We believe that having a clear distinction between use cases and contracts will improve the quality of both

The Treatment of Polymorphism and Modules in a Partial Evaluator

In this thesis we study aspects of specialisation by partial evaluation and compiler generation. After significant research during the last two decades, there are now powerful specialisers for several programming languages, such as LISP, Scheme, ML, and C. But some features of programming languages are still not handled by specialisers. We consider two such features: polymorphic types and modules. In our formalism of the binding-time analyser, we provide a solution to how to treat coercions in the context of polymorphism: coercions are used to make values more dynamic. Furthermore, since the semantics of the partial evaluator affect the binding-time analyser, we have formalised both the binding-time rules and the specialiser. We also discuss practical issues arising from our integration of a polymorphic binding-time analyser with a specialiser: the treatment of fix-points, program points, and bounded static variation. Where modules are concerned, we consider specialising a program consisting of several modules into a specialised version that also consists of several modules. This work relies heavily on a polymorphic binding-time analyser and a compiler generator. The polymorphic binding-time analyser works independently on each module. For each annotated module, we use a compiler generator to create a generating extension. Then we build generating extensions for complete programs, in much the same way as the original modules were put together into complete programs. The result of running all generating extensions is a collection of residual modules, which have a structure derived from the original program. But modules cause another problem. Previous specialisers produced a program consisting of one module, derived from a source program of one module. It is a weakness that the program being specialised imposes a limitation on the structure of the program generated, in this case, the number of modules. In this thesis we remove the restriction. Since we can obtain many modules by specialising one module, we remove an ``inherited limit\u27\u27 on the total number of modules. In this work, we need new types of annotation to control the specialisation. We have formalised a binding-time analyser for finding such annotations. We have also given the semantics of the partial evaluator